Tom,

I've managed to decipher the example so I know what I need to change, however I'm having a problem reading the correct register.

I'm trying to read the contents of the holding register DS1, which according to the manual, shares the same modbus hex address as the first inputs (X001) with the only difference being the preceding function code.

So using that info, I copied the sample read line-

{"\x01\x04\xE0\x00\x00\x01", 6, 0}, // Read inputs to MBRegisters[0]

and came up with

{"\x01\x03\xE0\x00\x00\x01", 6, 2},

However, this is still reading the input registers.

Having read the manual a bit more, a 04 code should also read the holding registers, but it somehow manages to read the input register???

Can anybody explain how to adress the holding registers?

Thanks

Moray

CLICKmodbus-8634.gif

Here's the relevant extract from the Click help file.

Thanks,
Moray

On 14 Nov 2013 13:38, <moray.cuthill@...> wrote:

 

Tom,

I've managed to decipher the example so I know what I need to change, however I'm having a problem reading the correct register.

I'm trying to read the contents of the holding register DS1, which according to the manual, shares the same modbus hex address as the first inputs (X001) with the only difference being the preceding function code.

So using that info, I copied the sample read line-

{"\x01\x04\xE0\x00\x00\x01", 6, 0}, // Read inputs to MBRegisters[0]

and came up with

{"\x01\x03\xE0\x00\x00\x01", 6, 2},

However, this is still reading the input registers.

Having read the manual a bit more, a 04 code should also read the holding registers, but it somehow manages to read the input register???

Can anybody explain how to adress the holding registers?

Thanks

Moray

 

---In dynomotion@yahoogroups.com, <tk@...> wrote:

Hi Moray,

The ModBus example is table driven so just by adding the Registers to the tables should cause the Registers to be Sent or Received to the MBregister Memory. But then you need to add more code to move the data to/from wherever you wish - in your case probably a persist.UserData Variable so the PC can read it.

HTH
Regards
TK

From: "moray.cuthill@..." <moray.cuthill@...>
To: DynoMotion@yahoogroups.com
Sent: Wednesday, November 13, 2013 5:24 AM
Subject: RE: RE: Re: Re: [DynoMotion] RE: Modbus example not working

Hi Tom,

I made up a crossover cable this morning (just X'ed the centre two wires), plugged it in, launched the sample thread, and everything burst into life how it should. Ticking the virtual bits in KMotion activates the PLC outputs, and activating the PLC inputs activates the virtual bits.

Now I just need to figure out how to read/write the required locations in the PLC...

Thanks

Moray

---In DynoMotion@yahoogroups.com, <moray.cuthill@...> wrote:

Tom,

that would explain why I was seeing activity on what should be the Click Tx line with no lights flashing on the Click. I'll make up a crossover cable in the morning and retry.

The Click is grounded on pins 1 and 6, so the ground should be fine.

I've uploaded the port 2 diagram to the files section for reference. The only physical difference from Port 1, is Port 1 doesn't have an RTS connection.

Thanks

Moray

---In DynoMotion@yahoogroups.com, <tk@...> wrote:

Hi Moray,

It does look like our numbering is backwards. Pin 1 is on the side near JP8. See attached.

Regards
TK

From: "moray.cuthill@..." <moray.cuthill@...>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, November 12, 2013 9:20 AM
Subject: RE: Re: [DynoMotion] RE: Modbus example not working

Hi Tom,

Can you confirm what side should be pin 1?

The diagram I found put it on the left side facing the connector with the KFlop/Kanalog upright, which would seem to tie in with 5v on pin 2 from the click.

Thanks

Moray

---In DynoMotion@yahoogroups.com, <tk@...> wrote:

Hi Moray,

I'm sorry I forgot that when KFLOP detects Kanalog as being present it automatically configures IO 45 as an Output and enables the UART to drive IO 45 so you can not use or toggle it as a general purpose Output.

So anyway what you describe is perfectly normal. And I believe you have proven what you are calling Pin 4 is Kanalog's Transmit Output. I think you are counting the pins backwards as that should be pin 3. You might check if you see data pulses on that pin when you run the KFLOP ModBus code.

The next step would be to determine which wire is the PLC's Transmit signal. I think it should be the one that is normally at -5V when not sending.

Then make sure the Transmit of each side is connected to the Receive of the opposite side.

I think you may need a crossover cable.

You might also want to use an Ohmmeter to verify the GND connection between the devices.

HTH

Regards

TK

On Nov 12, 2013, at 4:11 AM, <moray.cuthill@...> wrote:

Hi Tom,

I've just tried probing pins, and the problem seems to be that once bit 45 is set as an output, it locks on/high, with no way to turn it of. Trying to click the state low it immediately turns back on with no change in the output.

I tried disconnecting the Kanalog, and bit 45 can be turned off and on without any issues, and the voltage changes in JP7 pin 6 between 0 and 3.3V, so it would appear the KFlop itself is working as it should, and the problem only appears when the Kanalog is connected.

After reconnecting the Kanalog, I noticed that if bit 45 is set as an input, JP10 Pin4 goes to +5.3V, and as soon as bit45 is changed to an output, Pin 4 goes to -5.3V.

Measuring voltages at the edge of the ribbon cable where it plugs into the KFlop JP7, bit 45/pin 6 stays permanently high whenever configured as an output.

Bit 44/JP7 Pin5 when set as an input stays at 3.3V and will toggle normally when set as an output, regardless of how bit 45 is set.

This was all tested with the KFlop simply turned on and no user programmes downloaded.

Moray

---In DynoMotion@yahoogroups.com, <tk@...> wrote:

Hi Moray,

Kanalog contains a circuit to convert the 3.3V LVTTL UART signals coming from KFLOP Bit 45 to RS232 levels (basically +/- 5V). See:

http://www.dynomotion.com/Help/RS232/RS232.htm

The first thing would be to check that. Cycle power on KFLOP so it is in a default configuration. Then set bit 45 as an output and toggle it. Kanalog JP10 Pin3 should toggle RS232 levels relative to Kanalog GND.

Regards

TK

From: "moray.cuthill@..." <moray.cuthill@...>
To: DynoMotion@yahoogroups.com
Sent: Monday, November 11, 2013 4:51 AM
Subject: [DynoMotion] RE: Modbus example not working

Hi Tom,

I checked this with a scope this morning, and it appears the Kanalog is not outputting anything.

With the Click connected, I get 5V on Pin 2, with occasional pulses on Pin 4 (RX on the Kanalog). Everything else shows no signal (I never checked for any continuity to gnd, so can't tell you if they're tied to ground or not).

With the click disconnected, there's no activity on any of the pins, with the only exception Pin 4 sits steady at around -5V.

Any thoughts?

Thanks

Moray

---In dynomotion@yahoogroups.com, <tk@...> wrote:

Hi Moray,

Modbus is hard because there are many parts and if any part doesn't work then there is no result.

Maybe check at the hardware level with a scope or a voltmeter to see if signals are connected properly and have activity.

Also connect a PC to see that something is really being transmitted.

Regards
TK

From: "moray.cuthill@..." <moray.cuthill@...>
To: DynoMotion@yahoogroups.com
Sent: Saturday, November 9, 2013 2:14 PM
Subject: [DynoMotion] Modbus example not working

I've just been trying out the Modbus.c example supplied, however I can't get any repsonse from the Click PLC.

I have the Kanalog and Click connected with a straight-through cable, checked the Click is configured as per the example file (38400bps, 8bit, no parity, 1 stop), I download the file into a spare thread for testing, and all I get in the console is debug data saying it's failed and retrying. The Tx data dump appears to be ok.

There appears to be no output from the Kanalog, as nothing flashes on the Click.

I'll admit the example is a good bit more complicated than I'm used to, and I'm struggling with understanding exactly what is going.

Could somebody explain how the Click adressing works?

I've never used Modbus before, and I can't figure out how the addresses in the Kflop code translate into the Click modbus addresses.

If I'm understanding the code correctly, for the read, the high address is xE0, and low x00, yet the corresponding bits in Click are 0001 to 0008 hex.

And for the write, we have xE2 and x00, which somehow translate to 2000 hex upwards.

Having just typed that, I notice combining them has a pattern, but how E0 give 00, and E2 give 20?

All I'd like to acheive over modbus just now, is read inputs X6 and 7 on the PLC and store them to virtual bits, read the value stored in DS1 and store it in a user variable, and write a new value to DS2.

Thanks

Moray

PS. If only the Konnect had been launched a couple weeks earlier, I would of been saved the pain of setting up this PLC!

 

---In dynomotion@yahoogroups.com, <tk@...> wrote:

Hi Moray,

The ModBus example is table driven so just by adding the Registers to the tables should cause the Registers to be Sent or Received to the MBregister Memory.  But then you need to add more code to move the data to/from wherever you wish - in your case probably a persist.UserData Variable so the PC can read it.

HTH
Regards
TK

From: "moray.cuthill@..." <moray.cuthill@...>
To: DynoMotion@yahoogroups.com
Sent: Wednesday, November 13, 2013 5:24 AM
Subject: RE: RE: Re: Re: [DynoMotion] RE: Modbus example not working

 

Hi Tom,

 

I made up a crossover cable this morning (just X'ed the centre two wires), plugged it in, launched the sample thread, and everything burst into life how it should. Ticking the virtual bits in KMotion activates the PLC outputs, and activating the PLC inputs activates the virtual bits.

 

Now I just need to figure out how to read/write the required locations in the PLC...

 

Thanks

Moray

---In DynoMotion@yahoogroups.com, <moray.cuthill@...> wrote:

Tom,

 

that would explain why I was seeing activity on what should be the Click Tx line with no lights flashing on the Click. I'll make up a crossover cable in the morning and retry.

The Click is grounded on pins 1 and 6, so the ground should be fine.

 

I've uploaded the port 2 diagram to the files section for reference. The only physical difference from Port 1, is Port 1 doesn't have an RTS connection.

 

Thanks

Moray

 

---In DynoMotion@yahoogroups.com, <tk@...> wrote:

Hi Moray,

It does look like our numbering is backwards.  Pin 1 is on the side near JP8.  See attached.

Regards
TK

From: "moray.cuthill@..." <moray.cuthill@...>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, November 12, 2013 9:20 AM
Subject: RE: Re: [DynoMotion] RE: Modbus example not working

 

 Hi Tom,

Can you confirm what side should be pin 1?

The diagram I found put it on the left side facing the connector with the KFlop/Kanalog upright, which would seem to tie in with 5v on pin 2 from the click.

Thanks

Moray

---In DynoMotion@yahoogroups.com, <tk@...> wrote:

Hi Moray,

I'm sorry I forgot that when KFLOP detects Kanalog as being present it automatically configures IO 45 as an Output and enables the UART to drive IO 45 so you can not use or toggle it as a general purpose Output. 

So anyway what you describe is perfectly normal. And I believe you have proven what you are calling Pin 4 is Kanalog's Transmit Output.  I think you are counting the pins backwards as that should be pin 3.  You might check if you see data pulses on that pin when you run the KFLOP ModBus code. 

The next step would be to determine which wire is the PLC's Transmit signal. I think it should be the one that is normally at -5V when not sending.

Then make sure the Transmit of each side is connected to the Receive of the opposite side. 

I think you may need a crossover cable. 

You might also want to use an Ohmmeter to verify the GND connection between the devices. 

HTH

Regards

TK

On Nov 12, 2013, at 4:11 AM, <moray.cuthill@...> wrote:

 

Hi Tom,

 

I've just tried probing pins, and the problem seems to be that once bit 45 is set as an output, it locks on/high, with no way to turn it of. Trying to click the state low it immediately turns back on with no change in the output.

 

I tried disconnecting the Kanalog, and bit 45 can be turned off and on without any issues, and the voltage changes in JP7 pin 6 between 0 and 3.3V, so it would appear the KFlop itself is working as it should, and the problem only appears when the Kanalog is connected.

After reconnecting the Kanalog, I noticed that if bit 45 is set as an input, JP10 Pin4 goes to +5.3V, and as soon as bit45 is changed to an output, Pin 4 goes to -5.3V.

 

Measuring voltages at the edge of the ribbon cable where it plugs into the KFlop JP7, bit 45/pin 6 stays permanently high whenever configured as an output.

Bit 44/JP7 Pin5 when set as an input stays at 3.3V and will toggle normally when set as an output, regardless of how bit 45 is set.

 

This was all tested with the KFlop simply turned on and no user programmes downloaded.

 

Moray

 

---In DynoMotion@yahoogroups.com, <tk@...> wrote:

Hi Moray,

Kanalog contains a circuit to convert the 3.3V LVTTL UART signals coming from KFLOP Bit 45 to RS232 levels (basically +/- 5V).  See: 

http://www.dynomotion.com/Help/RS232/RS232.htm

The first thing would be to check that.  Cycle power on KFLOP so it is in a default configuration.  Then set bit 45 as an output and toggle it.  Kanalog JP10 Pin3 should toggle RS232 levels relative to Kanalog GND.

Regards

TK

From: "moray.cuthill@..." <moray.cuthill@...>
To: DynoMotion@yahoogroups.com
Sent: Monday, November 11, 2013 4:51 AM
Subject: [DynoMotion] RE: Modbus example not working

 

Hi Tom,

 

I checked this with a scope this morning, and it appears the Kanalog is not outputting anything.

With the Click connected, I get 5V on Pin 2, with occasional pulses on Pin 4 (RX on the Kanalog). Everything else shows no signal (I never checked for any continuity to gnd, so can't tell you if they're tied to ground or not).

With the click disconnected, there's no activity on any of the pins, with the only exception Pin 4 sits steady at around -5V.

 

Any thoughts?

 

Thanks

Moray

---In dynomotion@yahoogroups.com, <tk@...> wrote:

Hi Moray,

Modbus is hard because there are many parts and if any part doesn't work then there is no result.

Maybe check at the hardware level with a scope or a voltmeter to see if signals are connected properly and have activity.

Also connect a PC to see that something is really being transmitted.

Regards
TK

From: "moray.cuthill@..." <moray.cuthill@...>
To: DynoMotion@yahoogroups.com
Sent: Saturday, November 9, 2013 2:14 PM
Subject: [DynoMotion] Modbus example not working

 

I've just been trying out the Modbus.c example supplied, however I can't get any repsonse from the Click PLC.

 

I have the Kanalog and Click connected with a straight-through cable, checked the Click is configured as per the example file (38400bps, 8bit, no parity, 1 stop), I download the file into a spare thread for testing, and all I get in the console is debug data saying it's failed and retrying. The Tx data dump appears to be ok.

 

There appears to be no output from the Kanalog, as nothing flashes on the Click.

I'll admit the example is a good bit more complicated than I'm used to, and I'm struggling with understanding exactly what is going.

 

Could somebody explain how the Click adressing works?

I've never used Modbus before, and I can't figure out how the addresses in the Kflop code translate into the Click modbus addresses.

If I'm understanding the code correctly, for the read, the high address is xE0, and low x00, yet the corresponding bits in Click are 0001 to 0008 hex.

And for the write, we have xE2 and x00, which somehow translate to 2000 hex upwards.

Having just typed that, I notice combining them has a pattern, but how E0 give 00, and E2 give 20?

 

All I'd like to acheive over modbus just now, is read inputs X6 and 7 on the PLC and store them to virtual bits, read the value stored in DS1 and store it in a user variable, and write a new value to DS2.

 

Thanks

Moray

 

PS. If only the Konnect had been launched a couple weeks earlier, I would of been saved the pain of setting up this PLC!